To provide a bit of context, this was prompted by questions from @buxtonpaul about how to use the PTE bits, which involved setting up a null configuration for kernel-privileged pages. This then made obvious that the kernel pages were guarded by the same generation as user pages, and so sstatus would need to be swapped on kernel entry, which we believe is not the case currently. A better solution is to have a dedicated bit for the supervisor generation.

I misinterpreted the linked issue as being about kernel revocation and adding extra PTE bits, not about ensuring the kernel can actually load from kernel pages regardless of userspace's generation for userspace pages. Do we think that having sstatus.SCRG would form part of the story for kernel revocation? If there's a risk it's not what we'd want then it might be better to leave the sstatus bit (and PTE bit) reserved and say that there are no generation checks for S-mode pages. But probably it's something we'll need...

@jrtc27 Has the right of it: kernel access to user memory should generally be gated, for revocation purposes, as if it were performed by the user program.

The existing implementation performs its page sweeps by bypassing the PTE bits and their load barrier effect by using the "direct map" region of the address space, manually translating virtual addresses to (offset) physical ones. These accesses would look, to hardware, like the kernel accessing kernel mappings.

There is a proposal for a privileged "as user capability load, bypassing the CRG fault" instruction that would let us simplify much of that logic down to allowing pages to be swept directly in virtual address space (and possibly even concurrently with address space manipulation, currently emphatically prohibited due to the direct access to physical memory involved), but that's still a lot of engineering and measurement to make sure it's a good idea to be done.

All of that to say, I'm not sure a "CRGS" bit is the right idea. Until someone cracks kernel sweeping revocation, a much more challenging problem than for userspace memory, the kernel's own access to virtual memory will be to pages that are almost surely parked in some capability-permissive but CRG-less PTE configuration, assuming we have one of those. If we don't, it's probably simpler to just not raise CRG faults on PTEs with their U bit clear?

I'm certainly on-board with the far simpler, "non-user privileged pages don't ever get generation traps." With apologies to @tariqkurd-repo for dragging him through the mud, if we did agree on that one, would it be better to modify this pull request into that change to keep the history and discussion? Or start a new one? (Such a modification would basically be reverting most/all of it and adding a note somewhere. I guess.)

Two big changes here in the last commit:

1. remove sstatus.SCRG, and leave kernel space revocation for future
2. make PTE.CW mandatory, so the default is to not allow tagged caps to be stored for legacy OSs

and so Zcheripte includes CRG but not CW

Overall, this PR:

1. renames sstatus.CRG to sstatus.UCRG and makes it only tested in user mode
2. has no support for kernel space revocation (sstatus.SCRG is not specified)
3. makes PTE.CW mandatory and PTE.CRG+status.UCRG optional but strongly recommended